20: Give the two WordPress plugin questions a folder of their own - #34

What: moves Plugin_Checker, Plugin_Deactivator, their two interfaces and Loads_Plugin_Functions into src/Plugin/ as Checker, Deactivator, Contracts\Checker_Interface and Contracts\Deactivator_Interface. No behaviour changes.

Usage:

use Nexcess\PluginAbsorber\Plugin\Contracts\Checker_Interface;

$container->singleton( Checker_Interface::class, My_Checker::class );

Why this way:

These are one subject. They are the only files that touch WordPress's own plugin functions, and the trait that pulls in plugin.php has no other consumer — so a folder, rather than two root-level classes with their interfaces in the catch-all Contracts\ and their trait in the cross-cutting Traits\.

All four class and interface names lose the Plugin_ prefix, because the folder now spells it. That renames two host seams, which is free until 1.0.0 tags and would not be after; Plugin\Plugin_Checker_Interface stutters in every name and buys nothing a host can use. The trait keeps its prefix — the folder means "a WordPress plugin", the name means "the functions in plugin.php".

src/Contracts/ is down to Activator_Interface and Provider_Interface, and the root of src/ from eleven files to seven.

Summary by CodeRabbit

• Documentation

  • Updated architecture and extension guidance to reflect reorganized plugin checker and deactivator components.

• Refactor

  • Reorganized plugin-related components under a dedicated namespace with clearer names.
  • Updated conflict handling and dependency bindings to use the new component contracts.
  • Preserved existing plugin checking and deactivation behavior.

• Tests

  • Updated test coverage and fixtures to align with the reorganized plugin components and contracts.